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(57) Abstract 



A programming environment including a source code programming language comprising a plurality of programming constructs. A 
first set of wnstracts within the programming language are for expressing procedural operations performed on specified data. A second 
set of constructs (201) within programming language are for expressing complex data relationships of the specified data. A compiler (203) 
receives programmed source code comprising user-selected and arranged portions of the first and second set of constructs and generating 
inachme readable code (205) capable of implementing the procedural operations and complex data relationships expressed by the 
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SYSTEM FOR EXPRESSING COMPLEX DATA 
RELATIONSHIPS USING SIMPLE LANGUAGE 
CONSTRUCTS 

BACKGROUND OF THE INVENTION 

5 I Field of the Invention. 

The present invention relates, in general, to database software and 
computer program products and, more particularly, to software that relies on 
complex data relationships to obtain program data and instructions required 
for desired operation. 

10 2. Relevant Background. 

Software applications comprise coded instructions that are executable 
on a computer to process data (i.e., inputs) to generate a desired result (i.e., 
outputs). Increasingly, portions of the data and portions of the coded 
instructions (i.e., components) may be stored in a distributed fashion in 

15 database structures. These database structures are coupled directly or 
through networks to the computer on which the application is executing. 
Application behavior is defined by a data model that describes the data 
sources and relationships between the data sources. With the trend towards 
increasingly distributed systems, application and database development 

2 o increasingly require a means to express the data model that the application 
relies on. The present invention involves methods, systems, and computer 
program products used to access and manipulate data within an application 
that uses complex data sources and data models. 

In prior solutions, the application developer must rely heavily on 
2 5 database management systems (DBMS) and a knowledge of database 
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connectivity to implement an application using distributed data and program 
components. DBMS systems hide me low-level features of the undertying 
data base and its connectivity to the required target data. Using a DBMS 
data can be accessed by higher level database query languages such as' 
structured query language (SQL). While this eases the burden of managing 

dat mod T " C ° n,P0Unded ^ Pmblem °' ™" a ^ «*« 

data models. Apphcation developers must still express the complex data 

relationships using a combination of program language constructs and 

data ase-specific query language consuucta. ,„ practice, the application 

developer is forced to use either embedded query language (e.g.. SQL, 

constructs or other vendor proprietary DBMS-specific apportion 

programming interfaces (APIs). Both of these solutions fail to address the 

complex data modeling requirements that now exist and require the 

is ~ deUe ' OP * r,0haVeeX,en " eda,abaSeandWla " 9Ua9e 

Another trend in application development is to enable "domain experts" 
to author domain-specific application software. Domain experts are 
ntaU* with specific knowledge and experience in the doma*, in which the 

■o rr; ,o ° pera,e - ^ ^ ha - 

•0 aboutthedesTedbehaviorofappiicaUon, Typically, the domain expert is no. 
programmer, and so describes the desired application behavior to a 
programmer who has general knowiedge of .he program constants, operating 
systems, and platfomts ma. define the environment in which the appBcation is 
to operate. Unfortunately, the translaUon of an application frem a 
specification defined by a domain expert in.o code aumored by a pregrammer 
often resulb in unacceptable program code. Further, the domain expert 
cannot verify the programmers work and the programmer cannot verify the 
tdomarn experts work further complicating me development process. Hence 
a need exists for methods and computer implemented systems enabling a ' 
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domain expert to author application software without reliance on a computer 
programmer. 

As an example in the insurance industry, a "rating methodology" is 
typically developed by actuaries and business analysts who understand the 
5 insurance industry and customer needs. Typically the methodology is 
expressed in domain-specific terms and expressions that can be 
communicated easily between the analysts and actuaries. However, these 
domain specific terms and expressions do not readily translate into computer 
readable program code. Hence, computer programmers translate the rating 

10 methodology into a software implementation. This translation process is 

costly, error prone, and time consuming. Analysts who designed the original 
methodology cannot independently verify that the software translation is an 
accurate representation of the methodology. Moreover, the resulting software 
often contains machine specific program code that is not portable between 

15 mainframes, workstations, and personal computers. These factors alone or 
in combination tend to slow down the development cycle so that new 
applications as well as updates and modifications of existing applications take 
unacceptably long to complete. A need exits for a systems and method for . 
application development that provides a more streamlined, shorter 

20 development cycle. 

COBOL is widely used for common business applications because 
none of the programming languages that have become popular in the last 
three decades aid in overcoming the limitations set out above. Most of the 
advances embodied in popular programming languages since COBOL (e.g., 
25 BASIC, FORTRAN, C, C++, and JAVA) offer improvements to COBOL that 
are simply irrelevant to common business applications such as insurance 
rating that function essentially to transform database inputs into database 
outputs. Principle functionality desired in these applications includes: 



Simplified database access integrated into the language; 
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Support for direct manipulation of sets of records without complex 
loops, arrays, and the like; 

Runtime configuration based on business logic and constraints; 
Rule-based deduction; 

Automatic generation of user interface components; and 
Portability across all levels of enterprise computing. 

Conceptually, many limitations of the prior art result because the 
problem to be solved, i.e., implementing a business process, is merged with 
the programming logic that is used to access data required by the business 
process. Because of this merger, the application developer must know where 
the data and/or program components reside and what relationship^ those 
data and program components have to the location of other data and program 
components. Small changes in the business process due to expanded 
product portfolios, legislative changes or business practices required 
significant programming effort to implement. 

Similarly, porting an existing application to a new computer system 
requ,red a similar level of programming effort. Such changes alter the data 
mode, and force the application developer to make signtficant changes to the 
expression of that data model in the application. Hence, it becomes 
prohibitive to take advantage of new hardware and operating environments 
As a result, many existing business systems remain on older mainframe 
computer systems implemented in COBOL code that is bulky, costly and 
difficult to maintain. A need exists for expressing the complex data 
relationships used by a business application using simple language 
constructs. 

Further difficulty arises because the application developer programs in 
a genenc programming environment that fails to provide simple constructs to 
express common relationships that are inherent in databases Typical 
programming environments such as COBOL, C, C ++ and Java(tm) include a 
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variety of program constructs that ease the expression of procedural 
processes. However, even modern programming languages such as Java fail 
to provide programming constructs that directly express classic database 
relationships such as "many-to-one", group membership, and n many-to-one" 
5 relationships. Because of this, existing programming languages require the 
application developer to write to the DBMS using the vendor proprietary 
DBMS-specific API or query language. A need exists for a programming 
environment that expresses complex data relationships as built-in language 
constructs. 

10 SUMMARY OF THE INVENTION 

Briefly stated, the present invention involves a programming 
environment including a source code programming language comprising a 
plurality of programming constructs. A first set of constructs within the 
programming language are for expressing procedural operations performed 

15 on specified data. A second set of constructs within the programming 

language are for expressing complex data relationships of the specified data. 
A compiler receives programmed source code comprising user-selected and 
arranged portions of the first and second set of constructs and generating 
machine readable code capable of implementing the procedural operations 

20 and complex data relationships expressed by the source code. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a networked computer environment implementing the 
system, method and devices in accordance with the present invention; 

FIG. 2 illustrates basic program devices in accordance with an 
is embodiment of the present invention; 
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FIG. 3 illustrates in block diagram for interaction of program devices to 
implement a method in accordance with the present invention; 

Fig. 4a and Fig. 4b show example data structures illustrating the 
operation of the present invention; and 

Fig. 5a and Fig. 5b show example data structures illustrating additional 
operation in accordance with the present invention. 




The present invention is directed to a programming environment that 
enables an application developer to define inter-data relationships through an 
easy to understand and easy to express class syntax. The class syntax is 
used to author class definitions. In operation, the class definitions are used to 
create class instances at run time. In accordance with the present invention 
the class instances can be persistent (i.e., saved in a database) or local (i e ' 
trans,ent, non-persistent instances). A feature of the present invention is that 
both transient and persistent class instances are responsive to a common set 
of programming language constructs. In this way, the application developer 
does not need to have specific knowledge of whether a class instance is local 
or persistent. 

Another feature of the present invention is that the persistent classes 
define data constructs that support not only the data attributes of the local 
classes, but additional attributes that define classic data relationships such as 
membership, "many-to-many" connections, and "many-to-one« connections 
In this manner an application developer can program to the interface of 
pers,stent class without or any specific knowledge of the relationship(s) 
between the data manipulated by the class. 
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This combination of features allows an application developer to author 
an application that accesses data through both persistent and local data class 
instances without any knowledge of the data source or the data model 
describing the data relationships. In this manner the present invention greatly 
5 reduces the programming knowledge required to implement an application 
and lowers the entry barriers for domain-experts to implement, debug, and 
modify business applications. 

FIG. 1 illustrates a typical distributed computing environment in which 
the present invention may be implemented. In overview, FIG. 1 shows 
10 general and/or special purpose computers, workstations or personal 

computers that are connected via communications links of various types. 
Programs and data, many in the form of objects, are made available by 
various members of the system for execution and access by other members 
of the system. 

!5 The representative computer system shown in FIG. 1 includes a 

workstation or personal computer (PC) 1 1 1 and associated server 101 
coupled together through an appropriate communications link. The 
workstation 101 may include input/output ("I/O"), central processing unit 
("CPU") and memory sections (not shown) and an associated monitor for 

20 interacting with a user. A variety of input devices, such as a mouse or 

keyboard, form a portion of the workstation 101 and are coupled to the I/O 
section to provide user input data. 

Workstations 1 1 1 typically includes mass storage devices such as 
CDROM and hard disk devices (not shown) for read only and read-write 
25 storage. Additionally, workstation 1 1 1 may access external mass storage 
devices such as disk array 102 that is directly connected to server 101 and 
disk array 103 and tape storage 104 that are coupled through network or fiber 
116. Network 1 1 6 may be implemented as a wide area network (WAN), local 
area network (LAN) and may use any available technology for establishing 
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20 



25 



—-'on M. such as Ethernet. Fibre channe, (FC), Interne, Protocol 
n asynchronous toansfer mode (ATM), digital subscriber tine (DSL), and 
******* »6 may also couple to externa, LAN or WAN subnetwork 
such as LAN ,08 including worsens 112 and ,13 and a 
5 coupled together by a hub ,09. 

The computer program products containing mechanisms to effectuate 
«He appara.ua and metoods o, ,he presen, invention may reside in ,he 
mem portions o,,he™ons ,11, „ 2and ,13 as we,, as servers ,0, 
andllO^anyoftoevanousassociafed fouler mass storage devtoea 
» tope ddve ,04, dis, arrays 102 and 103. The computer progl 

Z pretr'? ,0 *** - ~ - ~ 0, 

117 " readi,y6m ^ fe " optical, magneto- 

op„ca, or Cher available machine readable encoding systems. 

The presen, Invention is desenbed in terms o, a new computer 
anguage caiied PROBOL™, although the teachings ofthe invention can be 

nlTng 2™ 3 "~°^P-— g entente 
mctudtng JAVA™ programming mMmmk pR0BQL 

Channa.pornL -nc. ,he assignee ol the present invemion and JAVA i t 
fademarfc olSun Microsystems. Inc., Palo Mo, California. The p ro en, 

shown nRG.2. Modularcomponentscanbareusedandareeasierto 
matn a,„. Updates can be made to on* one place in toe code, and problems 
usually have only one source. .ana problems 

■conJI 1 r ' 2 "" iS ' ra,eS ^ 8XemP ' a,y pm ^™*g environment including a 
comp„e„meenv,ronmenf20, and a -ron,ime environment. In toe 

is stored r ram 7 W d ° mai " "*"« — • « PROBOL souroe code toa, 
stoned, for example, as ASCII date. The source code is an expression of 
.neappLcationa desired Savior autoored using programming m 
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defined by the programming environment in accordance with the present 
invention. The source code comprises selected ones of the available 
constructs selected and arranged by the programmer. 

Two general classes of constructs are available in the programming 
5 environment in accordance with the present invention. First, general purpose 
programming constructs for expressing basic functions and processes useful 
in manipulating data. Second, database-specific constructs are provided for 
expressing complex data relationships typical of database operations. A 
significant feature of the present invention is that it provides a source-level 
.0 programming language that combines basic programming constructs with 
database constructs so that the program author can express the complex 
data relationships simply and directly. While special purpose development 
tools are often used, a text editor may suffice in some applications. 

Although source code authoring is illustrated as a single step it typically 
5 and desirably involves authoring multiple separate modules that are 

interlinked by cross references within the modules. Some of these modules 
comprise library modules that are predefined components within the 
programming environment. Other modules comprise user-authored 
components that are available for reuse. Yet other modules, often called 
o "main modules" are authored by the application developer or domain expert 
to call and interlink these components in a manner that expresses a desired 
application behavior. As described hereinafter, the programming environment 
in accordance with the present invention enables the construction of 
components such as local class 301 and database class 302 that 
5 encapsulate complex data relationships so that the author of the "main 
module" or the like that uses these components need not be aware of the 
complex data relationships expressed in the components. 

The source code is converted by a compiler 203 into machine readable 
code that implements the application as expressed by the programmer. The 
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complex date Unships are comp„ed .o SQL statements orstatements 
that access a partner DBMS API, for example and then expressed in Java 
oompNan, code. In «. manner, compilers penW the dihlculttasx of 
express,„ g the complex date relationships in a vendor pnoprietary DBMS- 
specific manner and hides .his complex^ from the applicaUon developer. 

While it is contemplated that compiler 203 could generate machine 
specfflc executable coda, in the preferred implementation shown in FIG 2 the 
machine readable code 205 comprises Java bytecodes typically provided in 
Java class Hies. The Java bytecodes are readable by a vidua, machine rather 

1Z T maCWne ' ** Pr ° Vide Si9nffiCan ' •*"*■" «■ 
PI independence. Java bytecodes are compact and podable which 

rr ,om ,or **» and ,rans,ertn9 a ™™ * * -*»* 

computer environment such as shown in FIG 1 . 

The bytecode representation 205 is then transferred to the runtime 
enwonmen, 202 to be processed by a program such as a Java Vlrtea, 
Mach,„e (JVM). A» JVMs understend the same bytecodes. so the bytecode 
<™ °< a ^va program can be run on any piatfom, with a JVM. ,„ ihls way. a 
JVM is a generic execution engine for Java bytecode - the JVM can be 
|«er , once for a given platfom, and then any bytecode pmgrem can be run 
by * As ,n conventional JVMs, the prefened implementation includes a 
bytecode verifler 204 and a bytecode interpreter 206 , ha, op«ona„y runs in 
parallel a dynamic compiler208 to provide interpreted native code (i e 
machme code, in a conventional manner. Unlike the interpreted code from 
interpreter 208. optimized code from compiler 208 can be saved for later 
reuse in code cache 212. 

environ!! Tt *" T" 1 inVen,i ° n " <* *• P^^ing 

imZr F ' G - N-rt— are the features tha, 

tmpact the step(s, involved in authoring source code in step 201 The 
programming environment in accordance w«h the present invention, lite other 
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general purpose programming environments, provides constructs for 
performing basic operations like mathematical calculations and conditional 
logic. These basic operations are coded in "expressions" 300 (shown in FIG. 
3) that are essential building blocks of applications. Although a complete 
5 understanding of the types of expressions is not necessary for an 

understanding of the present invention, by way of example expressions 
include constructs that manipulate arithmetic data (e.g., math functions), 
string data (e.g., concatenation and length functions), logical functions (e.g., 
Boolean functions), relationship functions (e.g., greater than, less than), and 
10 the like. It is contemplated that domain-specific expressions will be included 
in any particular implementation to ease the programming burden on the 
application developer. 

Cloud 303 in FIG. 3 represents an application executing in memory of 
a computer system such as workstation 1 1 1 shown in FIG. 1 . Expressions 

15 300 are used to define other constructs and carry out data operations. 
Expression 300 makes calls to local class 301 and database class 302 to 
create class instances illustrated by local object 304 and database object 306, 
respectively. One feature of the present invention is that expressions interact 
with local class 301 and database class 302 in a substantially identical 

2 o manner so that the application developer need not be aware of whether a 
particular object created by an expression is a local object 304 or a database 
object 306. 

An important feature in accordance with the present invention is that 
the class definition of database class 302 can be altered at runtime. For 
25 example, the attributes of a particular database class, and therefore the 
attributes of any instance of that class, can be dynamically altered. 

In a particular implementation the database class is altered, 
recompiled and stored back to the database. The recompilation process 
ensures that the modified database class is consistent with the original 

li 
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database class. In effect, the modified class 302 is like a subclass or 
extension of the original class 302. Subsequent instances of the altered 
database class inherit the modified attributes of the modified class 
description. This enables the application's behavior to be modified 
dynamically without halting the application or recompiling an entire 
application. In effect, the application can evolve to meet changing needs as 
opposed to more conventional processes which rewrite and recompile the 
application. 

Constructs within application 303 can also access library 307 which 
contains predefined library functions and procedures. Library functions and 
procedures may themselves create class instances and operate similarly to 
expressions 300 and are implemented as separate constructs primarily to 
encourage code modularity and reuse. During application execution, local 
objects 304 store the data used by expressions arid defined constructs during 
program execution. 

While local objects 304 in accordance with the present invention can 
manipulate table data in a variety of ways and provide a result to the calling 
express™ 300, they cannot directly change data that is outside the program 
itself (e.g., data in a database). To change external data the present 
•nvention uses database objects 306 that are instances of database classes 
302. Database classes 302 describe table data that can be used in a 
calculation, just like local classes 301 , but they are associated with a 
database table 305. As a result, when information is changed in a database 
object 306, the change is also made to its associated database table 305. 

Local objects 304 may include in their definition a reference to a 
database class 302. In this manner, a particular instance of the local object 
304 may include data from database 305, but cannot persistently manipulate 
that data without going through a database object 306. However, a database 
object 306 will not include a reference to a local class 301 because any 
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particular instance of a database class 302 does not know that the local class 
301 exists because local class 301 is not persistent. 

Expressions 300 include several commands, such as SAVE, MODIFY, 
and DELETE, that control the way a database class 302 interacts with its 
5 associated table 305. A SAVE command stores the object (e.g., the current 
values of its variables) to an associated table 305. A MODIFY command 
alters data in the object. A DELETE command deletes the object from 
persistent storage 305. From perspective of an expression 300, and hence 
the application developer writing expressions 300, the principle difference 

l o between local objects 304 and database objects 306 is that database objects 
306 will respond to a SAVE command by storing the database object 306 in 
persistent storage 305 whereas a local object 304 cannot respond to a save 
command. A local object 304 can be modified, and a DELETE command 
effects a local object by deleting it from cache, but does not effect any 

15 database table 305. Other commands available in expressions 300, such as 
WHEN, FOREACH, and TYPEACTION, control the flow of command 
execution and are used without regard to whether the object is a local objects 
301 or a database object 306. 

One reason that database classes 302 and local classes 301 can be 
2 o treated equally is that local classes 301 and database classes 302 

encapsulate complex data relationship information. Prior programming 
languages do not include constructs for expressing these relationships and 
therefore forced the application developer to access the vendor proprietary 
DBMS-specific definition and query languages or the DBMS API to express 
2 5 complex data relationships. 

A first effect of this is to enable simple to write database classes 302 
as the programmer does not need to express these relationships in a series 
of SQL commands, for example. A second effect of this is that local, transient 
classes 301 can be treated substantially similarly to database classes and 

13 
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can be used to represent complex data models even where there is no 
umten-y.no DBMS. In poor genera, purpose pregramming environments (e 
V,sua, Basic, C~ or Java) me task of expressing these compiex relationships 
without a DBMS was both difficult and non-intuitive thereby takJng application 
> development out of the hands of domain experts. 

To enable the expression of complex data relationships the 
programming environment in accordance with the present invention includes 
constructs ma, define a number of complex datatypes. Classic database 
relahonships include simple references, many-to-many connections 
membership, and one-to-many connections. ,„ accordance with the present 
invenbon. dass defMions include attnbutes that Indicate tha, instances of the 
class will implement the indicated relationships. 

FIG. 4a illustrates a simple reference relationship akin to a reference to 
a foreign key in a conventional DBMS. In the case of local objects 301 the 
class definition includes a pointer or other available reference expression 
pointing to another class. To ease descnptton, the class that contains the 
reference is referred to herein as a -reference class" and the class being 
pomted to is refetred to as the "support class". In the particular 
implementation, toe reference class cannot be a subclass, however the 
support class can be either a top-level class or a subclass. 

With a simple reference, any instance of the reference class is actually 
an .nstance of toe reference class in combination with an instance of the 
support dass. F.G. 4a shows a reference c,ass40, called "Employer which 
used ,o store infomtation about employers, and a first support dass 403 

cated S e cre.a^„sed,os.ore,nfom 1 aOonabou, t heem P loyerssecreta« 
A third suppo,, class 405 rated TimeJnJob . |s ^ (o suppoi) jnfomaUon 

about duration of toe Secretar/s employment To implement toe first 
reference a simple reference using a keyword "REFERENCE TO" is added to 
the Employer dass definition. To implement the second reference the 
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keyword "REFERENCE TO" is added to the Secretary class definition. In the 
illustration the Timejnjob class does not define any reference attributes. 
Any number of references can be chained in this manner within the class 
definition and so completely hidden from the application programmer. 

5 To create an instance of the class Employer an expression 300 

includes the Employer class as one of its arguments. The relationships 
shown in FIG. 4a are automatically traversed so that the instance 407 of 
Employer. Jim includes the sequence of values "Jim, 30, 0, Val, 40, 6". In 
memory, the object 407 does not include the references themselves, but 
10 instead contains the data referred to in the support classes 403 and 405. 

FIG. 4b shows an implementation in which the classes described in 
FIG. 4a are implemented as database classes. The principle difference is 
that database classes are associated with a database table structure shown 
in FIG. 4b. The database table 41 1 named Employer includes an entry for 
each employer and a field for each variable defined by the class. One field in 
table 41 1 includes a pointer to the Secretary table 413. Similarly, one field in 
Secretary table 413, includes a pointer to Time jnjob table 415. As will be 
appreciated, the data structure shown in FIG. 4a greatly resembles the table 
structure shown in FIG. 4b. As set out hereinbefore, the same expression 
300 directed at a database class 302 will result in an instance having the 
same content and behavior as instance 407, however, the data will have 
come from (and will be stored to) database tables 41 1, 413 and 415. 

A more complex data relationship is the classic "one-to-many" 
relationship which enables a reference object to refer to a sequence of 
25 objects. FIG. 5a illustrates a parent class 501 (i.e., the reference class) that 
includes a one-to-many reference (indicated as REF in FIG. 5a) to a child 
class 502 (i.e., the support class. In a particular implementation, the one-to- 
many reference is indicated by using the attribute "USING BACK 
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REFERENCE" in the variable definition with an argument identifying the child 
class 502. 

Conversely, child class 502 includes a membership reference 
(indicated as O-M REF in FIG. 5a) to parent class 501. An instance of the 
parent class automatically traverses the one-to-many relationship to create 
•nstances in the child class where the M.REF pointer refers back to the 
appropriate instance of the parent class. An instance 507 of -JOE" for 
example, in the parent class includes the variables from the parent class 501 
•n combination with the sequence instances of the child class 502 from the 
support class. In the database table view shown in FIG. 5b, each entry in the 
child table 512 includes a reference back to the associated entry in the parent 
table 51 1. 

A still more complex data relationship is the classic "many-to-many" 
relationship. Many-to-many relationships are useful in a conceptual mode, to 
qu-ckly capture what the business world see, A many-to-many relationship 
• -possible in a reIationa| database |{ ^ ^ ^ ^ ^ 

«n both directions and violates the 1st norma, form. In a logical mode, a 
many-to-many relationship is replaced by an associative entity. 

Many-to-many relationships describe a relation between two classes 
that allows each of them to create a sequence from instances of the other 
Both classes are considered reference classes and both must be top-level 
not subclasses. In a many-to-many reference the support class does not hold 
any data, but exists only to store the links between the two reference classes 
In accordance w*h the present invention, a many-to-many relationship can be 
defined ,n a database class by assigning a class variable the attribute "MANY 
TO MANY". The MANY TO MANY attribute uses a forward and a back 
reference to the support class 602 shown in FIG. 6. The first class 601 
-ncludes a REF that defines a many-to-many connection to the second class 
603, a forward reference to support class 602, and a back reference from 
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support class 602 as shown. A similar connection is expressed in the 
definition of second class 602. Also, the definition of support class 603 
includes membership references to the first and second class. 

The present invention is usefully understood in by way of a specific 
example involving a hotel room reservation application. The class 
descriptions shown in Table 1 illustrate how the application may be defined 
using local classes. 



LIBRARY MODULE HotelManagement IS 

PUBLIC CLASS Hotel IS 

ATTRIBUTE rooms IS {Room} 
END CLASS 



PUBLIC CLASS Reservation IS 

ATTRIBUTE registeredGuest IS STRING 

ATTRIBUTE checkln IS DATE 

ATTRIBUTE checkout IS DATE 

ATTRIBUTE rooms IS {Room. Reservations} 
END CLASS 



PUBLIC CLASS Room IS 

ATTRIBUTE roomnumber IS INTEGER 
ATTRIBUTE floor IS INTEGER 
ATTRIBUTE smoking IS BOOLEAN 
ATTRIBUTE maids IS {STRING} 
ATTRIBUTE reservations IS {Room} 

END CLASS 

END MODULE 

Table 1 



# Definition of Hotel Class. 

# variable "rooms" in class "Hotel" is a 
set of Room instances 

# Definition of "Reservation" Class. 



# variable "rooms" in class 
"Reservation" is a set of "reservation" 
instances of the support class "Room" 

# Definition of "Room" Class. 



# variable "rooms" in class 
"Reservation" is a set of "reservation" 
instances of the isupport class "Room" 



As seen in Table 1, the data model is expressed directly in the class 
10 descriptions by specifying variables that include instances or sequences of 
instances of other local classes defined in the module. In contrast, Table 2 
shows database class descriptions to implement an analogous data structure 
to that shown in FIG. 2. 
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LIBRARY MODULE HotelManagement IS 

PUBLIC DATABASE CLASS Hotel IS 
TABLE hotel 
KEY hotellD 

ACCESS FOR "ProboIAdmin" IS READ 
WRITE, CREATE, DELETE 
ATTRIBUTE rooms IS {Room} 
END CLASS^ REFERENCE Room.hotel 



PUBLIC DATABASE CLASS Reservation IS 
TABLE reservation 
KEYresID 

ACCESS FOR "ProboIAdmin" IS READ 
WRITE. CREATE, DELETE 
ATTRIBUTE registeredGuest IS STRING 
ATTRIBUTE checkln IS DATE 
ATTRIBUTE checkout IS DATE 

END A CLASS UTE r °° mS IS ( Room R eservations} 



PUBLIC DATABASE CLASS Room IS 
TABLE Room 
KEYroomID 

ACCESS FOR "ProboIAdmin" IS READ 
WRITE, CREATE, DELETE 
MEMBERSHIP REFERENCE hotel IS 
REFERENCE TO Hotel.rooms 
ATTRIBUTE roomnumber IS INTEGER 
ATTRIBUTE floor IS INTEGER 
ATTRIBUTE smoking IS BOOLEAN 
ATTRIBUTE maids IS {STRING} 

END A SJsS UTE reS6rVatl0ns ,S { Room > 



DATABASE CLASS Room Reservation 
SUBCLASS of Room, Reservation IS 

TABLE roomReservation 

KEY roomResID 

ACCESS FOR "ProbolAdmin" IS READ 
WRITE, CREATE, DELETE 

REFERENCE TO Reservations.rooms 

MEMBERSHIP REFERENCE room IS 
REFERENCE TO Room .reservations 
END CLASS 



# Definition of Hotel Class. 

# Declare table association 



# variable "rooms" in class "Hotel" is a 
set of Room instances from the Room 
Database class 

# Definition of "Reservation" Class. 



# variable "rooms" in class 
#"Reservation" is a set of 
Preservation" instances of #the 
support database class #"Room" 

# Definition of "Room" #Class. 



#DecIare membership Relationship to 
dB class #Hotel 



# variable "rooms" in class 
#"Reservatbn" is a set of 
Preservation" instances of #the 
support database class "Room" 
#Definition of support class 
# 

# 
# 

# 
# 

#Declare Membership references 
(e.g., forward and back references) 

# 



END MODULE 



Table 2 
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The database class description is somewhat more complex than the 
local class description, however, it can be appreciated that even the database 
class description uses programming constructs that express the data model 
without requiring any vendor proprietary DBMS-specific knowledge or SQL 
5 expertise. Because database class description shown in TABLE 2 is 

constructed in the same programming language set used to build local class 
descriptions shown in Table 1, the two descriptions are highly compatible, 
and in fact interchangeable in many instances. 

Tables 1 and 2 can be used to compare the coding complexity required 
10 to access local and database classes in accordance with the present 

invention as compared to a solution written in conventional SQL. It should be 
noted that that the compared SQL code doesn't provide the data relationships 
that were are used. Hence, the SQL versions below would in practice be 
larger and more complex. Below is an example that both reads and writes 
15 transparently to the database. As you can see from the example the same 
expressions can be used on either the local or database version of the class 
definitions. 

Task: Expression: 

Locate the first reservation where the Reservation ri IS FIRST(r IN 

registered guest is "John Doe. Reservation WHERE 

r.registeredGuest="JohnDoe w ) 
Locate ail of the rooms that "John Doe " has rl.rooms 
reserved. 

Add another room to the reservation. MODIFY rf ASSIGN(rooms <- 

©rl.rooms, room3)) 

Table 3 
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Task: 



SQL Expression: 



Locate all of the rooms that "John Doe B has 
reserved. 



Acid another room to the reservation. 



!2^^T?^^ the Se,ect reservation.reslD, 

registered guest is "John Doe. reservation. acllD, 

reservation. registeredguest, 
reservation.checkln, 
reservation .checkout from reservation 
where reservation.registeredguest 
-John Doe' 

Select roomReservation.roomResID, 
room.roomID, roomReservation.acllD, 
room.aclID from roomreservation, room 
where (roomreservation.reservation = 
4398063617922) and 
(roomreservation .room = room.roon-JD) 
insert into roomreservation (roomResID, 
acllD, reservation, room) values 
(4398063617971,2, 
4398063617922,439806361791 9) 

insert into roomreservation (roomResID, 
acllD, reservation, room) values 
(4398063617972, 2, 
4398063617922,4398063617920) 

insert into roomreservation (roomResID, 
acllD, reservation, room) values 
(4398063617973,2, 
4398063617922,4398063617921) 

delete from roomreservation where 
roomReservation.roomReslD = 
4398063617965 

delete from roon-treservation where 
roomReservation.roomR ResID = 
4398063617964 

Table 4 

As is apparent from a comparison of Tables 3 and 4, the programming 
environment in accordance with the present invention drastically reduces the 
complexity of data modeling in a fashion that alleviates the need for the 
application developer to manage the inter-data relationships of a complex 
data model. This allows the developer to rapidly develop applications by not 
having to understand the inherit complexity of the data that is being used. 
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Although the invention has been described and illustrated with a 
certain degree of particularity, it is understood that the present disclosure has 
been made only by way of example, and that numerous changes in the 
combination and arrangement of parts can be resorted to by those skilled in 
5 the art without departing from the spirit and scope of the invention, as 
hereinafter claimed. 
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WE CLAIM: 

1 • A computer implemented method for data processing in a 
computer including a processor and associated memory, the method 
comprising the steps of: 

defining a local data classes; 

defining a persistent data classes; 

instantiating a local data object from the local data class; 

at runtime, instantiating a first persistent object from the persistent data 
class, wherein the first persistent object and the local object have the same 
interface; 

dynamically altering at least one attribute of the persistent data class at 
runtime; and 

at runtime, instantiating a second persistent object from the altered 
persistent data class, wherein the first persistent object and the second 
persistent object have the same interface and differing behavior. 

2. The computer implemented method of claim 1 further 
comprising: 

providing procedural code that calls to the local and persistent classes 
without regard to whether the called class is local or persistent to cause the 
instantiation. 

3- The computer implemented method of claim 1 wherein the step 
of defining comprises storing programming constructs that define the 
structure, behavior, and interface of the data object. 

4. The computer implemented method of claim 1 wherein the step 
of instantiating comprises storing in memory a data structure that conforms to 
the structure of the class definition and is subject to the behavior defined in 
the dass definition. 
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5. The computer implemented method of claim 1 wherein the class 
instance is static and specifies data that cannot be altered at runtime; 

6. The computer implemented method of claim 1 wherein the class 
instance is dynamic and holds data that can be altered at runtime. 

5 7. The computer implemented method of claim 1 herein the class 

definition includes a relationship attribute that associates the instantiated 
object with another data object. 

8. The computer implemented method of claim 1 wherein the 
objects 1 interfaces expose the relationships defined in the objects' class 

10 definition. 

9. A computer implemented method for using an external database 
on a computer having a processor, a memory coupled to the processor, the 
method comprising the steps of: 

creating an instance of a first data object, the first data object having 
15 program constructs expressing data operations performed on transient data 
values and an interface; 

creating an instance of a second data object, the second data object 
having program constructs expressing data operations performed on 
persistent data values and an interface, wherein the second data object's 
20 interface is compatible with the first data object's interface. 

1 0. The computer implemented method of claim 9 further 
comprising: 

executing procedural code in main memory using the processor to call 
the first and second objects, wherein the procedural code includes a single 
25 set of program constructs to call the instance of the first data object and the 
instance of the second data object 
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11. The computer implemented method of claim 9 further 
comprising: 

storing definitions of the first and second objects in separate class files 
in the database. 

1 2. The computer implemented method of claim 9 wherein the 
second set of methods include methods for retrieving at least some of the 
variable's data from the database and storing at least some of the variable's 
data to the database. 

13. The computer implemented method of claim 9 wherein the first 
set of methods exclude methods for accessing the database. 

14. The computer implemented method of claim 9 wherein the 
second object is persistent so that its state is saved in the database when the 
second object is terminated; 

1 5. The computer implemented method of claim 9 further 
comprising the steps of: 

terminating the first object; 

instantiating the first object a second time, wherein the state of the first 
object state begins in a preselected initial state upon the second instantiation. 

1 6. The computer implemented method of claim 9 wherein the first 
object is static so that the value of its variables are defined by internal 
variable definitions within the object upon instantiation. 

1 7. The computer implemented method of claim 9 wherein the first 
object is dynamic so that the value of its variables are defined by external 
variables obtained by the object after instantiation. 
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18. A programming environment comprising: 

a source code programming language comprising a plurality of 
programming constructs; 

a first set of constructs within the programming language for 
5 expressing procedural operations performed on specified data; 

a second set of constructs within the programming language for 
expressing complex data relationships of the specified data; 

a compiler receiving programmed source code comprising user- 
selected and arranged portions of the first and second set of constructs and 
10 generating machine readable code capable of implementing the procedural 
operations and complex data relationships expressed by the source code. 

19. The programming environment of claim 18 wherein the second 
set of constructs comprises a construct for assigning to a variable an attribute 
indicating a relationship between the variable and an external database 

15 object. 

20. The programming environment of claim 1 8 wherein the second 
set of constructs comprises a construct for assigning to a variable an attribute 
indicating a one-to-many relationship between the variable and a plurality of 
external database objects. 

20 21 . The programming environment of claim 1 8 wherein the second 

set of constructs comprises a construct for assigning to a set of variables an 
attribute indicating a many-to-many relationship between the set of variables 
and a plurality of external database objects 
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